IV. REMARKS 

Claims 1-22 were presented for prosecution. Claims 1-4, 7-12, and 15-22 continue to be 
rejected under 35 USC 102(a) as being anticipated by Gunter Ollmann's "Custom HTML 
Authentication - Best Practices on Securing Custom HTML Authentication Procedures," 
hereinafter "Ollmann." Claims 5, 6, 13 and 14 were rejected under 35 USC 103(a) as being 
unpatentable over Ollmann in view of "Securing against Denial of Service Attacks (W3C). 
Applicant respectfully traverses the above rejections for the following reasons. 

In forming the rejections the Office notes that portions cited in prior Office Actions are 
only what the Examiner considers most pertinent, and that "it is the reference in its entirety that 
has been used to reject Applicant's claims." However, under 35 CFR 1.104(c)(2), when "a 
reference . . . describes inventions other than that claimed by the applicant, the particular part 
relied on must be designated as nearly as practicable." The reference in question teaches various 
approaches for handling HTML identification and authentication procedures. Applicant's 
claimed invention is not limited to dealing with login procedures, but deals with any type of 
request for a web resource. Accordingly, Applicant is entitled to know the specific passages that 
teach each and every aspect of the claimed invention, and merely relying on "the reference in its 
entirety" is clearly outside the bounds of 35 CFR 1.104(c)(2). 

Beginning with claim 2, the Office interprets page 4, lines 12-14 to teach that the system 
for responding stops issuing HTTP "OK" response codes and issues no response after a 
predetermined number of improper requests are detected. Applicant submits that this passage, 
by itself or even when viewed in its entirety, fails to teach such a feature. This section teaches 
providing an automatic lockout without informing the client after a number of authentication 
failures. The reference to not informing the client does not teach or suggest stopping the 
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issuance of HTTP "OK" response codes. Rather, it clearly indicates that a login screen would 
simply be redisplayed even though the client has been locked out. This thus allows "the correct 
authentication information [to be] later provided" to let the client know "that the account is 
currently locked out." When the paragraph is read in its entirety, it is clear that the paragraph 
could not reasonably be interpreted as stopping the issuance of HTTP "OK" response codes. 

With regard to claim 4 (and claim 12), the Office states that it "would like to draw 
attention to portions of both the Ollmann and W3C references." Claim 4 was not rejected based 
on the W3C reference either in a 102 or 103 rejection, so any citation to the W3C reference is 
improper in the context of the current Office Action and is not addressed herein. The cited 
portion of the Ollmann reference (page 8) refers to ensuring "that the content of the session ID is 
of the expected size and type." A session ID is not a request, as recited in the claim. Instead, a 
session ID is an identifier used by the application (i.e., server) to identify the client browser. It is 
gathered by the server after the client successfully logs in so that the client does not have to re- 
login after each page request. See page 6, last two paragraphs. Accordingly, Applicant submits 
that claim 4 (and similarly claim 12) is not anticipated. 

Claim 5 recites "wherein a request is deemed improper if an HTTP "post" or an HTTP 
"get" command is expected and neither an HTTP "post" nor an HTTP "get" command is 
received." The Office Action alleges that page 10 of W3C teaches various packet types that 
should be refused access. Applicant sees no reference or suggestion to unexpected requests. In 
fact, the references only address reply messages, not requests. A similar argument applies for 
claims 6, 13 and 14. Accordingly, Applicant respectfully requests withdrawal of the rejections to 
these claims. 
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Claims 8,10 and 17 are believed allowable for the reasons discussed above with claim 2. 
With regard to claim 1, Applicant recites "a system for detecting improper requests; and a system 
for responding to improper requests." Conversely, Ollmann explicitly recites forcing "any error 
or unexpected request to generate a HTTP OK response." Nowhere does Ollmann disclose a 
system for detecting "improper" requests. Accordingly, Applicant submits that claim 1 is not 
anticipated by Ollmann. 

Each of the claims not specifically addressed herein is believed allowable for the reasons 
stated above, as well as their own unique features. 

Applicant respectfully submits that the application is in condition for allowance. If the 
Examiner believes that anything further is necessary to place the application in condition for 
allowance, the Examiner is requested to contact Applicant's undersigned representative at the 
telephone number listed below. 



Dated: 7/28/08 

Hoffman Warnick LLC 
75 State Street 
Albany, NY 12207 
(518) 449-0044 - Telephone 
(518) 449-0047 - Facsimile 



Respectfully submitted, 




Michael F. Hoffman 
Reg. No. 40,019 
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